Skip to content

fix: migrate open file handles to new mock on rename#346

Draft
toddr-bot wants to merge 1 commit intocpan-authors:mainfrom
toddr-bot:koan.toddr.bot/fix-rename-open-handles
Draft

fix: migrate open file handles to new mock on rename#346
toddr-bot wants to merge 1 commit intocpan-authors:mainfrom
toddr-bot:koan.toddr.bot/fix-rename-open-handles

Conversation

@toddr-bot
Copy link
Copy Markdown
Collaborator

What

Open filehandles survive rename() and continue reading/writing the file data at its new path.

Why

After rename('/old', '/new'), any filehandle opened on /old lost access to the data. The tied FileHandle's weak data ref still pointed to the old mock object (whose contents was set to undef), causing reads to return EOF and writes to produce uninitialized-value warnings. This violated Unix semantics where open fds follow the inode.

How

During __rename, after transferring contents from old mock to new mock, iterate over $mock_old->{'fhs'} and re-point each handle's data weakref and file path to the new mock. The fhs tracking array is also migrated.

Testing

New t/rename_open_handle.t with 5 subtests covering: read after rename, write after rename, tell preservation, multiple handles, and eof behavior. Full suite passes (1591 tests, pre-existing fh-ref-leak.t failure only).

🤖 Generated with Claude Code

After rename(), open filehandles lost access to data because each
handle's weak 'data' reference still pointed to the old mock (whose
contents was set to undef). This violated Unix semantics where open
fds follow the inode, not the directory entry.

The fix re-points each handle's data weakref and file path to the new
mock during rename, matching real filesystem behavior.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant